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ABSTRACT 



A state-of-the-art management information system which 
would allow a Type Command to efficiently control assigned 
assets by thorough integration of the many currently distinct 
management systems is critical in this era of rapid technolog- 
ical growth, data overabundance, and expanding naval commit- 
ments. A significant problem with the current development of 
such a system is its inherent large size and a requirement to 
use an unproven methodology. Information Engineering (IE) . 
This thesis analyzes the modernization of the Type Commander 
Headquarters Automated Information System, THAIS, identifies 
problems related to the effort and discusses the use of IE on 
a major redesign project. 
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INTRODUCTION 



I . 

The U.S. Navy requires large database systems to manage its 
many activities. The design of such database systems has 
proven to be inadequate for long term system usage and 
maintenance. Instead of relatively simple revisions to a well 
established system, whole new systems are designed to accomod- 
ate new requirements. This situation is inefficient and 
wasteful of hard to acquire public funds. 

The complicated development of these expansive systems 
requires an ever increasing effort in project management and 
design. Consequently, software development methodologies such 
as Fourth Generation Techniques and Prototyping and Strategic 
Information Systems Planning methodologies such as Information 
Engineering (IE) are in use to optimize planning and design 
efforts in terms of time, monetary expenditures, and end user 
satisfaction (Ref. l:p. 1]. However, the effectiveness of 
each methodology is questionable since they are relatively new 
techniques and have not been used extensively on large 
software projects such as the THAIS modernization. 

The U.S. Navy has defined a requirement for a large 
database system which will allow for the efficient management 
of very extensive data on a large number of units. The 
system, the Type Commander's Automated Information System or 
THAIS, in use since 1986, has been undergoing constant 
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revision . 



The next revision will be much more extensive and 



incorporate several smaller database systems which are 
currently independent, separately-managed systems. Rapid 
technology change and rapid software applications development, 
along with increasing amounts of organizational data, has 
driven the requirement for the utilization of a comprehensive 
methodology. This methodology must be capable of accurate, 
efficient and timely project completion which meets with end 
user satisfaction. 

Information Engineering (IE) is an appropriate methodology 
and was chosen for the Navy project, modernization of THAIS. 
It is conducive to effective data modeling and supports a 
variety of database software programs. This methodology 
provides for strategic planning, design, and implementation of 
an organization's information system in an efficient, accurate 
manner. [Ref. 2:p. 221] U.S. Navy interest in IE stems from 
its focus on data and the derivation of information from the 
data. The relationship of IE to the structured discipline of 
engineering, its leading edge of technology status, and the 
Navy's long tradition of being at the forefront of technologi- 
cal development may also be contributing factors to the Navy' s 
captivation with IE and Computer Aided Software Engineering 
(CASE) technology. 

Utilization of new development methods is not without 
risks. Untested methods can result in lower quality software. 
Many times product quality assurance and testing is accom- 
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plished by letting the end user discover product shortfalls. 
Untried or untested cutting edge techniques become burdensome 
to the end user rather than beneficial. 

Software qpjality is a very elusive term. End users expect 
software, especially expensive software, to be error free and 
fully documented. Developers, often constrained by budgets, 
are interested in achieving cjuality but only to the point 
where it is cost effective. Oftentimes a software product is 
incomplete because of this situation which leaves a dissatis- 
fied user with a non-quality product. A formal definition of 
software quality is: 

Conformance to explicitly stated functional and performance 
requirements, explicitly documented development standards, 
and implicit characteristics that are expected of all 
professionally developed software. [Ref. 3:p. 433] 

The Department of the Navy (DON) requires many large, 
unique software programs to operate ADP facilities, control 
weapon systems and to manage operational readiness. The 
management of these large software projects is very cumbersome 
and oftentimes inefficient. [Ref. 4:p. 65] Through the use 
of management controls such as program reviews, status reports 
on cost and schedule adherence, and contractually imposed 
standards, the DON attempts to monitor "...cost overruns, 
milestone slips, omitted requirements, incomplete require- 
ments, and inadequate deliverables." [Ref. 4;p. 65] The first 
two items can be controlled by proper project management. The 
last three items can be remedied by substantial user input 
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during software planning and development and by the establish- 
ment of a stable information systems architecture. 

A stable architecture must be built around organizational 
data but this is not easily accomplished. Inadequate^ out-of- 
date data may be difficult to format meaningfully. Data 
integrity is difficult to ensure since project data is often 
proprietary and the contractor performs the project analysis. 
Unwillingness to share proprietary data makes data sharing a 
barrier between the DON and private contractors. Cooperation 
is needed to ensure successful project completion. Project 
management may choose cost and schedule adherence over 
productivity and efficiency during data analysis leading to a 
lack of program quality. End products may fall short of the 
end user's expectations and may even be unusable due to a lack 
of end user input during the design process. The time lag 
between discovery of problems or the request for additional 
requirements and the actual implementation of the corrective 
changes or new requirements is often too great to be effec- 
tive. The above problems lead to poor product quality and 
excessive time to project completion. [Ref. 4:p. 66] 

The introduction of IE sought to solve problems associated 
with traditional design such as (1) overemphasis of applica- 
tions on functions/processes and underemphasis on data which 
leads to a lack of understanding of long term information 
needs ^ (2) lack of productivity and standardization from 
underutilization of CASE tools ^ and (3) lack of user invlove- 
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ment in the design process. Utilization of IE assures an 
organization, through development of a stable informations 
system architecture, of the delivery of a higher quality 
product . 

The DON' s interest with IE thus exhibits a desire to 
produce high qpaality products which are user friendly and user 
supported. However, due to modification of the IE Methodology 
in the THAIS modernization project, rapid prototyping was 
introduced to complete the first module. Through an analysis 
of the DON'S modernization of THAIS, this thesis will deter- 
mine the effectiveness of Information Engineering on a large 
database design project. The issues of quality control, 
project management, end user involvement and end user support 
will be addressed. 

The thesis will address the following questions: 

1. What are the benefits which Information Engineering adds 
to the software development process and are these benefits 
worth the time, effort, and funding rec[uired to develop 
the software? 

2 . What are the advantages and disadvantages of exporting the 
methodology used for THAIS modernization to other type 
commands? 

3. How is quality control improved with Information Engineer- 

ing? 

4. Why did process modeling fail in the THAIS modernization 
project? 

5. Can Information Engineering be altered in order to be 
effective on large scale projects? 

6. Is Information Engineering an effective methodology for 
the design and implementation of a large database project 
based on the results of the THAIS modernization? 
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Chapter II provides the background information of the THAIS 
modernization project and also on Information Engineering and 
the decision for its utilization on the THAIS project. 

Chapter III discusses the detailed data modeling processes 
specific to Information Engineering and the THAIS moderniza- 
tion project, 

Chapter IV discusses the aspects of quality assurance 
required in a successful software design project. In addition 
it discusses how Information Engineering ensures quality in 
its methodology. 

Chapter V discusses CNSP^s dissatisfaction with Information 
Engineering on the THAIS modernization project and the 
resultant corrective action taken by the DON to successfully 
complete the intitial module of the project. 

Chapter VI provides conclusions and recommendations for the 
DON to use for future projects where Information Engineering 
is utilized. 
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II . 



BACKGROUND 



A . PROJECT BACKGROUND 

Any large organization has vast amounts of data which it 
uses for day-to-day operations as well as in support of its 
strategic plans. Many organizations cannot foresee the future 
nor envision their information needs. Without foresight, it 
becomes exceedingly difficult to develop an information system 
capable of directing an organization toward its strategic 
goals. Large investments required for information systems 
development, insufficient understanding of organizational data 
and processes, and lack of long term focus make it difficult 
for management to be committed to project development. Ad hoc 
response to emerging information needs becomes commonplace 
which can be overly expensive in the long run. [Ref. 5:p. 6] 
The U.S. Navy has defined strategic goals and objectives 
but does not possess a sound infrastructure for development of 
its information resources. An ad hoc response tendency has 
been widespread but commitment to the development of a sound 
information systems infrastructure has reversed the trend. 
This infrastructure will provide several enabling capabili- 
ties : 

- Mechanisms to share data resources. 

- A communications network that permits widespread 
interconnectivity . 

- A productive process for developing application soft- 
ware . 
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- High quality technical support services (technology 
assessment, technical support of users and products, 
training services, etc.)* [Ref. 5:p. 5] 

Another problem associated with the extensive organiza- 
tional data is the difficulty in accumulating and compiling 
information from the assorted data. An answer to this data 
manageability problem is in the utilization of an automated 
information system. 

The military is highly dependent on automated informa- 
tion systems (AIS) for the reliable operation and mainte- 
nance of its weapon systems and other critical military 
operations such as the management of spare parts as well as 
day-to-day administrative and financial transactions 
involving personnel payroll, and contract management. These 
functions are vital for the efficient operation of the 
United States defense establishment. The Department of 
Defense (DOD) currently spends about $9 billion each year on 
general purpose automated data processing equipment, soft- 
ware, and related services. This "information technology 
budget" represents a commitment by DOD to tens of billions 
of dollars in future expenditures for the development and 
acquisition of new automated information systems. 

[ Re f . 6 : p . 1 ] 

The U.S. Navy realized in 1976 that a system was needed at 
the Type Commander level. As a result. Type Command Headquar- 
ters Automated Information System, THAIS, was initiated. 

1. What is THAIS ? 

THAIS was conceived in 1976 as a special project at the 
direction of the Chief of Naval Operations OP-091. A study 
titled "ADP Software Support for Type Commander Headquarters - 
Requirements Study - Phase I" was completed but consequently 
shelved until 1978 when the Commander in Chief, Atlantic Fleet 
became interested. The economic analysis required for 
development approval was completed in November 1979 and the 
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initial Functional Description (FD) appeared in December 1980. 
Development began in 1981 by NABDAC Norfolk, whose Commanding 
Officer also acted as Deputy Project Manager with the Primary 
Project Manager being Commander, Naval Data Automation 
Command. [Ref. 7:pp. 1-2] 

THAIS was envisioned as a system to ease the burden of 
information management at the Type Commander level. The 
stated THAIS missions are: 

- Provide on-line, interactive management information system 
to 7 TYCOMS. 

- Build backbone databases in 10 functional areas. 

- Improve data reliability. 

- Accelerate management report preparation time. 

- Expand data utility. 

- Provide earlier problem recognition. 

- Make more efficient use of available resources. 

[ Re f . 8 : p . 15] 

The system originally involved a prototype which ran on 
a UNIVAC System 80 but was converted to run on Honeywell DPS- 
6 machines in 1983. After successful implementation on the 
DPS- 6 machines, the system was designated initially operation- 
al capable and became utilized by Commander Naval Surface 
Forces Atlantic (CNSL) . The system continued to gain interest 
and additional requirements were rapidly requested, ultimately 
calling for a new revision of the software to be produced. 
[Ref. 7:pp. 1-3] 

The first revision, THAIS Phase II, was initiated in 1984 
and completed in 1986. [Ref. 7:p. 3] Revisions occurred 

rapidly since that time with revision two in 1987/88, revision 
three in 1988, and revisions four and five in 1989. The 
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current version, 5.1, was installed in June 1990. However, 
modernization efforts continue. [Ref. 8:p. 13] 

2. Why Update THAIS ? 

Growth of the U.S. Navy since the origination of THAIS 
and rapid and extensive increases in information requirements 
have combined to necessitate a larger system capacity and more 
extensive capabilities. Figure 1 demonstrates the current 
utilization of THAIS throughout various Type Commands. THAIS 
usage started with CNSL in 1984 and spread to all six Type 
Commands, Commander-in-Chief Pacific, and Commander, Second 
Fleet by 1990. As depicted in Figure 1, each commander does 
not utilize each module. As the system expands and the 
database is refined, module usage will increase. Widespread 
THAIS usage at the Type Commander level is important because 
each Type Commander utilizes similar data and has similar 
information requirements and flows in its daily operations. 
All Type Commanders are challenged with the problem of 
managing a very large and dynamic yet essential database. The 
database also possesses the problem of various security 
classifications within a single database but many users with 
varying levels of security clearances require access. 
Increased information sharing between Type Commanders could 
significantly reduce similar problems within various commands. 

Concurrently with the U.S. Navy's increased demand for 
information, computer technology developed rapidly. The ADA 
programming language was introduced to high level DON person- 
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Figure 1 THAIS Utilization by Type Coitunand [Ref. 7;p. 14] 
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nel who sought to utilize the language for many new projects. 
Several software development methodologies evolved during this 
period of information technology growth which the U.S. Navy 
could apply to solve its increased information system require- 
ments and utilize the ADA language. 



B. INFORMATION ENGINEERING BACKGROUND 

There are alternative software development methodologies 
which are variations on the classical Software Development 
Methodology or the "waterfall" method. Prototyping, Fourth 
Generation Techniques and SAGE-SDM are examples of variations 
and improvements on the classical methodology. Each has its 
positive and negative characteristics. Figures 2-5 depict 
these methodologies. 

Prototyping is an iterative process of quickly designing 
and building system models. The positive characteristics are: 
hastening of overall system development time and high degree 
of end user involvement during the design. On the negative 
side, the end user is more aware of the , velopment status and 
may often like what appears to be a complete, working model of 
the system and therefore expects to use the system as is but 
is quite disappointed when informed of the prototype' s 
inherently incomplete nature. The end user often demands to 
use the incomplete version without regard for the software 
quality or system maintainability. Also, sacrifices in design 
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The Classical Method 
[Ref. l:p. 2] 
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are made to speed development which may remain with the system 
after the prototype is accepted. The developer may neglect or 
may not have the funding to correct the design to the original 
specifications. [Ref. l:p. 5] 

Fourth Generation Techniques is a methodology which 
includes several software tools "...which enable the software 
developer to specify some characteristic of software at a high 
level." [Ref. l:p. 5] These characteristics are screen 
design, code generation, report generation, graphics, and 
several others. As a positive aspect, for small or medium 
applications this methodology decreases time required for the 
analysis and design phases. Larger projects require more time 
and often do not realize any significant time savings over the 
classical design methodology. [Ref. l:p. 6] 

SAGE-SDM, was developed by the Department of Energy's Idaho 
National Engineering Laboratory (INEL) and is an amalgamation 
of the Classical Methodology, Prototyping, and Fourth Genera- 
tion Techniques. This methodology involves the user exten- 
sively which imparts a sense of ownership, reduces development 
time significantly, and is conducive to the design situation 
where the user requirements are hard to define. One major 
drawback to this methodology is the compromises made during 
implementation to satisfy time constraints in order to deliver 
a system which is usable per the customer's request. Although 
the developer would like it to be perfected before turning it 



14 



over to the user, he is often forced into delivering an 
incomplete product. [Ref. l:pp. 7-8] 

The above Software Development Methodologies (SDM) are 
intended for use in conjunction with a Strategic Information 
Systems Planning Methodology (SISP) . IE was chosen as the 
SISP for the THAIS modernization project and SAGE-SDM was 
chosen as the SDM. The need to utilize both methodologies 
arises from the requirement to develop a staJDle information 
systems architecture and follow up with an efficient software 
application development. 

1 . What is Information Engineering ? 

There are several definitions of Information Engineer- 
ing which may differ somewhat but each is centered on modeling 
organizational data and each emphasizes the creation of a 
stable information systems architecture. One interpretation 
is that of James Martin, one of the major contributors to the 
IE Methodology, who states that IE is: 

...a process by which information systems are developed 
that precisely support the objectives of the business enter- 
prise. The lEM' SjM logical, common sense progression of 
steps is rigid enough to ensure comprehensiveness and 
accuracy, yet flexible enough to model precisely the unique- 
ness and idiosyncrasies of the business. 

The lEM' S to focus on the information needs of the entire 
enterprise, rather than compartmentalized data processing 
functions, is an essential point of differentiation from 
other philosophies. [Ref. 9:p. 2] 

Clive Finkelstein, another major contributor to the 
development of IE, describes IE as a strategic development 
approach which "...is an integrated set of technicpaes which 
lead from strategic planning to the implementation of informa- 
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tion systems which directly support those plans (of the 
business)." [Ref. 10:p. 2.2] 

Richard Hackathorn and Jahangir Karimi further explain 

the primary focus of IE as being directed: 

...specifically at translating a corporate focus (a strate- 
gic plan, expressed as organizational mission statement) 
into an information systems architecture (ISA) , which can be 
directly translated into data, application, and geographic 
architectures. [Ref. 11 :p. 203] 

These descriptions emphasize the importance of a 
strategic perspective throughout the development process. 
Although it is not stated, a data-centered approach is assumed 
in these definitions. This is a major differentiation from 
and improvement upon the previously discussed SDM' s . Center- 
ing the development around data which has been well-defined by 
key personnel within the organization allows for easier 
adaptation to new requirements over the lifetime of the 
system. [Ref. 12 :p. 129] During development, data is 

isolated and modeled based on its importance to the organiza- 
tion and not on the current use of the data. Data is central 
to this methodology but processes, technology and management 
issues are also keys to a successful implementation. [Ref. 
13 :p. 246] Figure 6 depicts the IE methodology. 

There are several versions of IE, none of which has 
stood out as a preeminent, all-encompassing method [Ref. 
ll:p. 205]. Clive Finklestein is the founder of the Informa- 
tion Engineering Systems Corporation (lESC) , which is the 
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Figure 6 The IE Methodology [Ref. 2:p. 222] 



17 



contractor for the IE portion of the THAIS modernization, so 
his interpretation of IE will be described. 

This IE method is comprised of three broad phases which 
are subdivided into stages as follows; 

- Analysis Phase [Ref. 2;pp. 223,241] 

- Project Scope Stage 

- Identify Project Area 

- Select Project Software 

- Establish Project Plan 

- Establish Project Teams 

- Set Project Budget and Funding 

- Schedule IE Workshops 

- Strategic Modeling Stage 

- Strategic Modeling 

- Strategic Objectives Modeling 

- Strategic Refinement 

- Tactical Modeling Stage 

- Tactical Modeling 

- Tactical Objectives Modeling 

- Tactical Refinement 

- Operational Modeling Stage 

- Current Systems Modeling 

- Design Phase [Ref. 2:p. 229] 

- An automated phase that uses a design dictionary. It 

comprises Strategic, Tactical and Operational Design. 

- Generation Phase [Ref. 2:p. 231] 

- This phase defines implementation strategies appropriate 

to each part of the integrated s , ategic and tactical 

data models. 

A knowledge base is a primary aspect of IE which 
differentiates it from other methodologies. This knowledge 
base is a collection of data models, data flow diagrams, 
process specifications and any other pertinent planning and 
analysis phase products. Design phase products such as screen 
and report designs are also stored as they are created. The 
knowledge base is important because it serves as an active 
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repository which CASE tools can utilize. It can be accessed 
to automatically create planning or design products which 
improves development time and provides for easier maintenance 
and revisions. [Ref. 13:p. 247] 

2 . Why Utilize Information Engineering ? 

IE is an adaptive, contemporary methodology which can 
help an organization define its data resources and develop a 
complete information system which is compatible with the 
organization's strategic goals. It employs CASE technology 
which allows it to draw from a knowledge base to integrate and 
automate planning, analysis, design and code generation 
functions . IE structures information to enable managers to 
readily obtain key information without time consuming data 
processing. Fourth Generation Languages aid in timely project 
completion and cost cutting through code reusability and code 
library generation for future revisions or for other projects. 
The specific advantages of IE are: 

- It is based on a precise model of the business enterprise, 
and therefore can effectively support its objectives. 

- Intensive user involvement, with the help of diagrammatic 
techniques, ensures the systems' completeness and accura- 
cy. 

- Its emphasis on data as well as applications provides a 
stable, long-term foundation for processes and business 
rules that change as the business changes. 

- CASE tools add speed and enhance accuracy, and make 
possible development by users as new needs and require- 
ments arise. 

- It is accompanied by comprehensive briefings and guide- 
lines for managing the role changes for managers, users, 
analysts and programmers. 

- It includes participation in an extensive research and 
development program that continues to refine and enhance 
the methods it embodies . 
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- It achieves data consolidation: IE draws includes cross- 
checking steps both manual and automated, to identify 
redundant versions of data. 

- It is highly automated: Both strategic and tactical plans 
and data are captured by expert systems in an expert 
design dictionary. [Ref. 9:p. 10] and [Ref. 2:p. 234] 

The U.S. Navy chose IE over other methodologies because 
of the above considerations and because it fits well with the 
Navy's commitment to planning for the future. With reduced 
appropriations and constant if not increasing commitments, 
increasing organizational data, expanding technology and 
extended data sharing, the U.S. Navy demanded a methodology 
capable of satisfying these needs. 

THAIS is an important system because it links the vast 
data concerning individual naval units with the strategic 
goals of the U.S. Navy through the high level management of 
the Type Commanders. Information Engineering is an excellent 
method for matching strategic planning with a sound informa- 
tion systems architecture through strategic, tactical and 
operational modeling of organizational data and the associated 
processes. For these reasons. Information Engineering is the 
chosen methodology for use on the THAIS modernization project. 
The specific aspects of a key portion of IE, data modeling, is 
discussed in the following chapter. 
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III. 



MODELING THE DATA 



Today's organizations are saturated with data. The 
management of information gleaned from these data is a key 
issue during strategic organizational planning. Oftentimes, 
senior management of large organizations is unfamiliar with an 
information-^rich realm in which to plan since they were 
educated and oriented to their business when information was 
relatively scarce and information management was virtually 
nonexistent. These same senior executives are expected to 
create an effective strategic plan with a wealth of informa- 
tion, some of which they cannot envision. [Ref. 5:p. 4] The 
intrinsic value of the information provided from accumulated 
data cannot be ignored as it may provide answers to as yet 
unknown questions which could directly affect the future of an 
organization. Data modeling significantly aids an organiza- 
tion in its data refinement and creation of information 
essential to organizational management. 

A primary problem associated with utilizing information for 
strategic planning is in developing a management information 
system which contains accurate data and provides the appropri- 
ate information to the proper personnel. The process of 
analyzing data and fitting it into an information system is 
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known as data modeling and is a central part of IE. 

Data modeling offers an analysis and design method. 

It helps to define the requirements of users, and then to 
design systems that satisfy those needs. Data modeling 
leads to development of logical data base designs based on 
user's needs. [Ref. 2:p. 59] 

Data modeling consists of three stages: strategic, tactical, 
and operational. The data refinement process throughout these 
stages produces a data model which consists of an entity list 
and a data map. The data model represents fundamental 
organizational data, data attributes, and data relationships. 
It is also the primary product of IE and the primary input to 
the software development process. [Ref. 2:pp. 33-37] 

Data identification and verification is not the only 
function of this stage of development. The strategic model 
provides a broad perspective of the organization's goals. The 
tactical model must define statements which support the 
strategic goals but are specific enough to generate management 
rules. IE, which utilizes expert systems (lESC utilizes USER: 
Expert Systems) to automate the design process, will use the 
management rules as part of the expert system' s knowledge 
base. The process of devising the rules is known as tactical 
objectives modeling. 

Tactical objectives apply to the operational end of the 
organization. As for strategic objectives, tactical objec- 
tives are also called performance indicators. They must be 
measurable and decompose into work, requiring effort to 
achieve. [Ref. 2:p. 202] 

Each modeling stage provides a distinct level of data 
refinement which will be described in the following sections. 
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A. STRATEGIC DATA MODELING 



The Strategic Modeling stage of an IE project focuses on 
identifying the critical success factors which enable an 
organization to attain its strategic objectives. Strategic 
goals, often vague or misunderstood by many executives, must 
be delineated and verified in order to ascertain proper 
critical success factors. Once this is accomplished, the 
strategic model can be outlined. The project flow through 
each modeling stage within IE and the relationship to imple- 
mentation is depicted in Figure 7. The specific steps of data 
modeling are depicted in Figure 8. 

A strategic model comprises high-level strategic 
entities of interest to senior management of a project area. 
These strategic entities are so called because they contain 
primary and foreign key attributes to establish associations 
between related entities. [Ref. 2:p. 203] 

The strategic model represents an organization in terms of 
its data, not in terms of the processes which utilize the data 
[Ref. 14:p. 2.8]. This is an important point because the 

processes may change but the data is stable. "Although the 
information requirements of executives change from month to 
month, the basic data that represents an enterprise does not 
change much unless the enterprise is itself drastically 
changed." [Ref. 15:p. 23] 

The goal of this stage is to create a stable strategic 
model which will spawn stable tactical and operational models 
which will lead to the creation of a dynamic yet sound 
management information system. 
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Strategic Modeling Tactical Modeling Operations Modeling 




Figure 7 Data Modeling Flow within IE [Ref 2:p.244] 
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Figure 8 




Data Modeling Steps [Ref. 2:p. 272] 
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The Information Engineering Systems Corporation (lESC) has 
an effective procedure for conducting strategic modeling. 
This organization holds a workshop with executives to verify 
strategic goals, determine organizational policies, identify 
key personnel, establish milestones and determine performance 
monitoring procedures. [Ref. 14 :p. 2.15] 

As a contractor for the THAIS redesign project, lESC 
conducted a Strategic Modeling workshop in January 1990 with 
the Commander Naval Surface Forces Pacific (CNSP) staff, which 
served as the prototype site for the THAIS modernization, and 
other associated project personnel. The result was a division 
of data into seven functional areas: 

- Logistic Equipment (including Casualty Reports or 
CASREPS) 

- Logistic Supply 

- Shore Based Facilities 

- Readiness 

- Employment 

- Financial Management 

- Performance Monitoring [Ref. 16 :p. 1] 

The current THAIS version has eleven separate subsystems and 
databases with much redundant data. The proposed revision 
will consolidate the data into one database and resolve the 
data redundancy issue. An example of data redundancy within 
CNSP is the requirement for CASREP data in the Logistic 
Equipment area and in the Readiness area. Since both areas 
require the same data, one dateibase should suffice and would 
be more appropriate since data currency and consistency would 
be more easily maintained. However, currently two distinct 
databases are utilized. 
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A strategic objective of the redesign effort was to give 
development priority to those functional areas most affected 
by a. shutdown of the Honeywell DPS- 6 computers [Ref. 16 :p. 1] . 
The operating expenses of the Honeywell computers will be 
transfered to each Type Command from Naval Computer and 
Telecommunication Command (NCTC) at the end of FY91 which is 
a factor driving the completion of the redesign by the end of 
FY91 . 

As part of the THAIS modernization, a PC based system would 
replace the Honeywell minicomputers. The PC based system is 
must less expensive to maintain and is believed to be more 
flexible in terms of ease of use and information transfer 
between type commanders and subcommands. [Ref. 18 :p. 2] For 
example, with the present configuration, status reports are 
mailed to subcommands who manually annotate corrections and 
mail them back to the type commander who then enters the 
corrections into the database. With a PC based system, 
reports can be corrected on a local database, the corrections 
stored on floppy discs and then mailed to the Type Commander 
for automatic entry into the master database. 

Several functional areas were identified to be critical in 
the event of a Honeywell computer shutdown. These areas were 
Logistic Equipment (CASREP) , Readiness and Employment. [Ref. 
16 :p. 1] The CASREP area became the first modeled area. 
Tactical modeling, the next stage after strategic modeling, 
started with the CASREP module on 05 March 1990 [Ref. 16:p. 1] . 
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There are three rules which link the strategic plan to 



organizational data. 

- Rule 1: Policies and issues relate directly to entities. 

- Rule 2: Goals and objectives relate directly to attrib- 

utes . 

- Rule 3: Strategies and tactics relate directly to associa- 

tions. [Ref. 17:p. 19.15] 

An example of a report generated as a result of strategic 
modeling is the Policy Report, Figure 9. This report is the 
result of the need to relate organizational policies to data 
entities or to create a policy when a group of entities lack 
an associated policy. [Ref. 17 :p. 19.15] Other outputs of 

strategic modeling are: 

- Entity Report 

- Attribute Report 

- Association Report 

- Extended Purpose Report 

- Graphical Data Map 



B. TACTICAL DATA MODELING 

The tactical modeling stage of IE is concerned with 
refining strategic objectives to a level consistent with a 
specific functional area. Managers who participated in 
strategic modelng direct the mid-level managers in the 
definition of strategic objectives to obtained from a specific 
functional area at the tactical level. [Ref. 2:p. 196] 

A tactical model comprises lower-level tactical entities 
of interest mainly to middle management of a project area. 
These tactical entities contain non-key attributes (called 
tactical attributes) which provide detailed data of interest 
to these middle managers. [Ref. 2:p. 203] 
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PdHcv Report : Active 
Functional Area t 



READINESS REPORTING 



Page I 1 Oete I 22-Jul-W90 



ADVANCED TRAINING POlia 

ASSURE UNITS ARE READY FOR ADVANCED TRAINING WHEN CHOPPED TO C3F. 

linked to the folloning entities (cancelled links in parentheses) 

LOGISTICS-EOUIFtfENT 

H/W. 

FtRSONNEL 

(PERSON) , UNPLANNED LOSS ASSIGNMENT. 

READINESS REPORTING 

ORGANIZATION TRAINING PLAN, FERSON TRAINING REQUIREMENT. 



BILLET (3UALIFICATI0NS 

Shipboard billet qualifications will be identified and fsaintained. 



linked to the following entities (cancelled links in parentheses) 



PERSOW^L 

BILLET. 

READINESS REPORTING 

BILLET TP.AININ6 REQUIREMENT. 



deplcjtient readiness 

COMNAVSURFPAC Hi 1 1 endeavor to have all assets ready to deploy Ml in all priRary Mission areas. 

linked to the following entities (cancelled links in parentheses) 

LOGISTICS-EQUIPMENT 

H/W. 



Figure 9 THAIS Policy Report 
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The strategic data model is expanded into functional areas, 
seven in the case of CNSP, at the tactical level as represent- 
ed by Figure 10. An organizational policy determined during 




Figure 10 Expansion of Strategic Model into Tactical and 
Operational Models [Ref. 2:p. 246] 

strategic modeling such as "Mobile \ , ts are required to 
undertake a certain set of training, exercises, and inspec- 
tions," is used to identify data entities which are then 
further refined during tactical modeling. One entity associ- 
ated with the above policy is the Employment Scheduling module 
entity "organization." Middle and operational managers are 
queried on the aspects of their functions such as the utiliza- 
tion of CASREP data in each organization or the relationship 
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of organization data to the Readiness area. Data related to 



these functions are defined and analyzed. Unneeded or 
redundant data is discarded. [Ref. 14 :p. 2.16] The model is 
streamlined but all pertinent data according to the "experts" 
or operational managers is captured. For example^ the entity 
mentioned above^ "organization^ " is subsequently refined or 
normalized into nine entities. These entities are: 



“ organization 

- organization 

- organization 
~ organization 

- organization 

- organization 
~ organization 
~ organization 

- organization 

- organization 

- organization 
~ organization 

- organization 



location 

location reason 

location reporting category 

role 

structure 

structure category 
structure reason 
type 

requirement 
resource readiness 
TRADA history 
training plan 



Involvement by management throughout the data refinement is 
critical since it creates a feeling of ownership and responsi- 
bility to make the system work. 



A basic premise of data modeling is that some data are 



related to other data. The relationships are determined 
through user involvement and are automatically documented in 
a data dictionary. Physical depictions of data models, called 
data maps, are then generated for analysis and verification. 
[Ref. 15;p. 28] Figure 11 is a partial Readiness module data 
map which shows the relationships of organizations as modeled 
within the module. 
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Figure 11 Partial THAIS Datamap 
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Tactical modeling ensures, through data structuring, that 
data are defined independently of their utilization in 
organizational processes [Ref. 15;p. 260]. Data must be 
modeled in this fashion. Modeling data according to its use 
will result in a poor system architecture in that if the 
processes change, as is often the case, the architectural 
stability will be jeopardized. The result is large reinvest- 
ment in time and money to design a new system based on the new 
processes. Tactical modeling seeks to eliminate this problem 
by ensuring that data are isolated and modeled without regard 
to any process thereby securing a stable architecture. [Ref. 
15 :p. 5] Figure 12 represents a tactical modeling output, the 
Entity Purpose Report. This report lists each entity in the 
functional area and its purpose for existing in the database. 
Other outputs of this stage are the same as strategic model- 
ing, with the exception of the Policy Report, but are limited 
to a specific functional area instead of the whole organiza- 
tion . 

Upon completion of tactical refinement the tactical model 
is further refined in the third and final data modeling 
iteration, the Operations Data Modeling stage. 

C. OPERATIONS DATA MODELING 

This stage is a formal cross-check of strategic and 
tactical data modeling. It uses organizational documents to 
verify that the modeled data is complete and appropriate. 
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TYPE COMMANDER READINESS REPORTING 

Entity PirpoM fteoort ; Active Pige ; 2 Date : 

Functional Area : READINESS REPORTING 



Entity 

Purpose 


; CASREP IPWTS AMPIIFICATIDN 
: CAmiy REPORT IPWTS WIPLIFICATION 

Captures a»*pliTying reearks relative to the Iparts section of a CASREP requisition. 


Entity 

Purpose 


i CASREP FACTORS CONTROLING ETR 
: CASREP FACTORS C0MTR0LL1N6 ESTIHATED TlflE OF REPAIR 

Allows recording of factors impacting or justifying the estinated repair date reported on a CASREP. 


Entity 

Purpose 


I CASREP HfVlOHARE STRUCTURE 
1 CASUALTY REPORT mmm STRUCT!^ 

Identifies a relationship between a CASREP and the hardware associated with a CASREP. This entity is used to 
indicate the hardware that is doKi (being CASREPed) as well as any hardware whose effectiveness is iiapacted by 
the down hardware. 


Entity 

Purpose 


: CASREP HARDWARE STRUCTURE TVPE 
j CASREP HARDWARE STRXTURE TYPE 

Contains the valid values applied to a piece of hardware associated with a casrep. Indicates whether the 
hardware is down or iepacted by the downed hardware, i.e. chilled water syste* is downed, the sonar is 
affected. 


Entity 

Purpose 


; CASREP MESSA8E 
1 CASREP MESSAGE 

Used to report the status of significant equipnwnt casualties. Cowparing this with the fICC for equipeent will 
allow the TYCOM to verify the urgency of the readiness category reporteo by an organization. 


EnMty 

Purpose 


: CASREP PRIORITY 
t CASREP PRIORITY 

Used to determine a priority rating (1 thru 9) of a CASREP message based on a c-rating (C2, C3, C4) and a 
deployeent status. 


Entity 

Purpose 


: CASREP READINESS RATING 
: CASREP READINESS RATING 

Identifies the level of readiness (which is the level of iepact on the ships capability to perform its 
assigned missions) »4ien a hardware iteA is reported on a CASREP as being down. 



Figure 12 THAIS Entity Purpose Report 
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This stage does not require upper or middle level management 

but can be completed by data administrators or, in the case of 

THAIS, by Type Command staff. [Ref. 2:p. 229] 

An operations model comprises day-to-day operational 
level entities (called operations entities) containing 
detailed non-key attributes of interest to staff at the 
operational level of an organization. [Ref. 2;p. 203] 

The inputs to this stage are the same as in the tactical 
stage: management statements, entities, attributes, associa- 
tions, and purposes describing the importance of entities. 
[Ref. 19 :p. 2.11] These inputs are massaged by the end users 
with the help of the IE project personnel into final products. 
To continue the example from tactical modeling, the entities 
organization, organization location, and organization type are 
characterized as alphanumeric with length 50, upper case 
alphanumeric with length 30, and upper case alphanumeric with 
length 1, respectively, during the operational modeling stage. 
Final data refinement is attained through the following: 
Attribute characterization: 

Capture the physical characteristics of the attributes, 
i.e. data storage type, data length, and domain of 
values . 

Populate Static Reference Tables: 

Define values for any new, and populate all static 
reference tables. 

Data Access Authority Validation; 

Re-affirm the data access authority for each entity with 
respect to each functional user community related to the 
system. 

Data System Storage Size Estimating: 

Estimate the number of records in each entity, the % 
change, % new, % deleted, average record lifetime. 

Data Capture Strategy Plan: 

Identify specific data capture points (organizations or 
places) , authorities, frequencies, and policies for all 
data to be captured by the new system. 

[Ref. 19:p. APP 3.8] 
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One technique for eliminating redundancy, precisely 
capturing information requirements, and integrating complex 
data architectures is normalization. [Ref. 19:p. 5.28] 

Normalization aligns each attribute to an entity and distin- 
guishes entities which may be identical but have different 
names or independent entities with the same name. It simply 
provides a clear understanding of each entity and attribute. 
[Ref. 2:p. 94] Data normalization can be taken to several 

levels generally no higher than fifth but theoretically, 
although impractical, to the N*'*' normal form. Some normaliza- 
tion is esential because it provides flexibility in a rela- 
tional data structure. [Ref. 20 :p. 1] The definitions of the 
first through fifth business normalization steps, as used by 
lESC on this project, are listed below. An example accompa- 
nies each step. An underlined attribute indicates a primary 
key and double parentheses indicate a repeating group of 
attributes. [Ref. 2:p. 151] 

First Business Normal Form (IBNF) : 

Identify and remove repeating group attributes to another 
entity. The primary key of this othf , entity is made up of 
a compound key, ..., or instead anoth... unique key based on 
the business needs. 

IBNF entities for PRODUCT: 

PRODUCT ( product number #, product name, cost price, 
selling price, warehouse number#, warehouse 
address, quantity on hand) 

PRODUCT SUPPLIER ( product number #, supplier number #, 

supplier name, supplier address) 

Second Business Normal Form (2BNF) : 

Identify and remove those attributes into another entity 
which are only partially dependent on the primary key and 
also dependent on one or more other key attributes, or which 
are dependent on only part of the compound key and possibly 
one or more other key attributes . 
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2BNF entities for PRODUCT: 

PRODUCT ( product number #, product name, selling price, 
warehouse number#, warehouse address, 
quantity on hand) 

PRODUCT SUPPLIER ( product number #, supplier number #, 

cost price) 

SUPPLIER ( supplier number #, supplier name, supplier 
address ) 

Third Business Normal Form (3BNF) : 

Identify and remove into another entity those attributes 
which are dependent on a key other than the primary (or 
compound) key . 

3BNF entities for PRODUCT: 

PRODUCT ( product number #, product name, selling price, 
warehouse number#, quantity on hand) 

PRODUCT SUPPLIER ( product number #, supplier number #, 

cost price) 

SUPPLIER ( supplier number #, supplier name, supplier 
address ) 

WAREHOUSE (warehouse number#, warehouse address) 

Fourth Business Normal Form (4BNF) : 

An entity is said to be in fourth business normal form 
when: (1) it is in third business normal form and its 

attributes depend not only upon the entire primary key, but 
also on the value of the key; or (2) when an attribute has 
been relocated from an entity where it is optional to an 
entity where it is wholly dependent on the key and must 
exist, and so is mandatory. 

4BNF entities for ORDER: 

CUSTOMER ( customer number #, customer name, customer 
address, customer account balance, customer 
credit limit) 

PRODUCT ( product number #, product name, quantity on 
hand, quantity on order) 

ORDER ( order number #, delivery address, order date, 
customer number#) 

ORDER LINE ITEM ( order number #, order line number #, 

agreed sales price, discount percent, 
product number#) 

ORDER LINE ITEM TYPE ( order line item type id #, order 

line item type description) 
ORDER LINE ITEM ROLE ( order number #, order line 

number # , order line item type 
id#) 

OUTSTANDING LINE ITEM ( order number #, order line 

number#, product quantity 
ordered) 

BACKORDERED LINE ITEM ( order number #, order line 

number # , quantity on backorder) 
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SHIPPED LINE ITEM ( order number #, order line number #, 

product quantity shipped, date 
shipped) 

Fifth Business Normal Form (5BNF) : 

An entity is in fifth business normal form if its 
dependencies on occurrences of the same entity or entity 
type have been moved into a structure entity. 

5BNF structure entity for PRODUCT: 

PRODUCT STRUCTURE ( product number #, product type #, 

sequence #, product number #, product 
type # , quantity for assembly) 

Once the details are captured and verified through normal- 
ization, a stable operations data model is generated. The 
model now contains all data needed for implementation. 
However, before implementation begins, the information 
processing requirements must be delineated and this is 
accomplished through Process Modeling. 

D. PROCESS MODELING 

Processes, specific procedures that describe the actual 
data flow throughout an organization, are essential for an 
effective implementation of the database design as modeled in 
the strategic, tactical, and operational stages. It is impor- 
tant to note that in IE, processes are defined without regard 
to any physical means. This differentiates it from the 
Structured System Design' s process modeling which does 
incorporate physical data flow means. [Ref. 12:p. 181] The 

idea is to capture the logic of the data flow not the physical 
means by which it occurs. The question "What is to be done?" 
must be specifically answered by the users, not "How do you do 
your job?" [Ref. 19:p. APP 3.4] 
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Process Modeling is accomplished by: 

Specifying Business Events 

Business events are things that happen in the environ- 
ment outside of the system that cause the system to 
react. The system reaction may be to; 

- Record the facts related to the event 

- Produce specific products related to the event 

- Cause further actions to be taken within the system 

Identifying System Functions 

System functions are the definition of the system 
reaction to the occurence of business events. The 
definition must include: 

- Input data requirements 

- Output data requirements 

- Internal data transformations 

Procedure Data Model 

Each System Function will be defined as a Procedure, or 
set of Procedures, which will accomplish the function. 
These procedures are to be written to express the 'What 
is to be done,' not the 'How to do it' and should be 
written in business terms related to the data transfor- 
mations necessary to accomplish the process. 

Specifying Interactive User Interfaces 

Interactive User Interfaces are the visual portrayals of 
the behavior of the system in response to user actions. 
They include: 

- Control Menus 

- Data Entry Screens 

- Response Screens 

- Product Request Screens 

Specifying Pre-Planned System Products 

System Products include all the various report formats 
needed to satisfy information requirements for business 
purposes. They include: 

- Pre-specif ied On-line Screen Reports 

- Pre-specified On-line Printer Reports 

- Pre-specified Batch Reports 

Defining External System Interface Requirements 

Specify the information requirements for recurring data 
transfer to or from other automated systems. This 
includes new automated interfaces to systems outside the 
organization, as well as 'refresh' interfaces from 
existing systems that will be part of the new overall 
system. 
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Defining Data Migration Requirements 

Specify the information requirements for data loading to 
initialize the physical database. These are one-time, 
or seldom used routines that will not be a recurring, 
regular part of the new overall system. 

[Ref. 19:p. APR 3.4] 

Implementation is dependent upon stcible data and process 
models. The data model provides the necessary data and the 
process models demonstrate the flow of the data through the 
organization. The combined results are the functional 
requirements of the system. Firm functional requirements 
allow the system to be implemented on a variety of hardware 
systems. [Ref. 19:p. APP 3.10] 

Modeling can be a long (several months) , difficult and 
tedious process. Throughout the process, the opportunity for 
errors exists. Each management level of an organization views 
data and information differently. Consequently, insignificant 
data is often modeled and processes are inaccurately de- 
scribed. The result is an incorrect and possibly ineffective 
database. Quality control must be exercised in order to 
ensure the development of a complete and accurate database and 
will be discussed in the following chapter. Quality control 
as it relates to the THAIS project will be discussed in the 
following chapter. 
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IV. QUALITY CONTROL of the THAIS MODERNIZATION PROJECT 



THAIS modernization, like all software projects, is subject 
to errors. In order to minimize errors, a certain amount of 
quality control must be exercised throughout the project's 
life cycle. The difference between a project which fulfills 
requirements specifications and meets with the user' s satis- 
faction and one which does not is determined by the amount of 
quality control exercised. Typical problems associated with 
a management information system design and implementation and 
which effective quality control can alleviate are: 

- Software-naive customers who are usually interested only 
in software output. 

- Poorly defined, but often highly complex, customer objec- 
tives . 

- A high turnover rate for personnel, resulting in the 
continual review of existing software and high training 
costs . 

- Externally or internally generated constraints (e.g., 
cost, time, and manpower limitations) 

- Personnel of widely varying levels of skill. 

[Ref . 21 : p . 465] 

Before quality control on the THAIS modernization project 
is discussed it is helpful to describe a framework for 
evaluating quality control. 



A. CRITERIA FOR QUALITY CONTROL 

There are many methods for evaluating the quality of a 
project but each method must emphasize three points: 



Software requirements are the foundation from which 
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quality is measured. Lack of conformance to requirements 
is lack of quality. 

- Specified standards define a set of development criteria 
that guide the manner in which software is engineered. 

If criteria are not followed, lack of quality will almost 
surely result . 

- There is a set of implicit recfuirements that often goes 
unmentioned (e.g., the desire for good maintainability) . 
If software conforms to its explicit recpairements but 
fails to meet implicit recjuirements, software quality is 
suspect. [Ref. 3:p. 433] 

Quality control is affected in three areas. These areas 
are a product's operational characteristics, a product's 
ability to undergo change, and a product's adaptability to new 
environments [Ref. 3:p. 433]. Eleven quality factors have 

been proposed to help quantify quality control within these 
three areas. These quality factors are: 

- Maintainability (Can I fix it?) 

- Flexibility (Can I change it?) 

- Testability (Can I test it?) 

- Portability (Will I be able to use it on another machine?) 

- Reusability (Will I be able to reuse some of the 

software?) 

- Interoperability (Will I be able to interface it with 

another system?) 

- Correctness (Does it do what I want?) 

- Reliability (Does it do it accurat‘='ly all of the time?) 

- Efficiency (Will it run on my hardw , i as well as it can?) 

- Integrity (Is it secure?) 

- Usability (Can I run it?) [Ref. 3;p. 434] 

The above factors can be utilized to evaluate the relative 
quality of a project simply by asking each of the associated 
qpaestions. In order to ensure a high level of quality 
throughout a project, these factors should be reviewed 
constantly. Although they originally were proposed in the 
context of software quality control, these factors should not 
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be limited in scope to the physical software design and 
characteristics. Project management has an equal responsibil- 
ity with the software development teaim to provide quality 
control throughout a project's life cycle. 

B. THAIS PROJECT MANAGEMENT QUALITY CONTROL 

THAIS management is divivded into two levels. The overall 
management of the THAIS modernization occurs at NCTC, Washing- 
ton. The second level is local management at the prototype 
site, NCTS San Diego and CNSP, San Diego, and at the deputy 
program manager site, NARDAC Norfolk. [Ref* 22] 

1 , Overall Project Management Quality Control 

At the upper level, quality control involves coordinat- 
ing and monitoring the funding of the project. Policy is set 
as to the direction which the project should take when various 
critical events occur or milestones are reached. Management 
at this level must focus on the factors which directly affect 
the long term utilization of the system. These factors are: 

- flexibility 

- reusability 

- interoperability 

- portability [Ref. 22] 

Flexibility is important because the operational 
environment of the system is dynamic and future contingencies 
must be accounted for. Reusability is an increasingly 
important factor since monetary constraints drive the need to 
cut costs wherever possible. Reusability directly leads to a 
savings in time which leads to monetary savings. Upper level 
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management must also be concerned with interoperability since 
the possibility exists to couple this system to systems 
already in existence or future systems. THAIS is expected to 
be interoperble with the Operational Support System (OSS) 
which runs on SUN 4300 machines, the SNAP III system which is 
still under development, and the Maintenance Resource Manage- 
ment System (MRMS) [Ref. 22] . Portability must be sought in 
order to ensure utilization on several different hardware 
configurations since there is no standard hardware system at 
the Type Command level and below. At a recent program review, 
a THAIS submodule was demonstrated on a Zenith Z-248, a COMPAQ 
PC, a UNISYS 386, and a Zenith laptop PC to ensure portabili- 
ty. The submodule worked effectively on each system. [Ref. 
22 ] 

Quality control at this upper level is monitored 
primarily through program reviews. Direction of the project 
must be reaffirmed to the Prototype site and the Central 
Design Activity (CDA) , NARDAC Norfolk, who must then ensure 
that all quality factors are satisfied. In order to closely 
monitor the quality control, NCTC also receives monthly status 
reports from the CDA and conducts quarterly reviews at the 
CDA. 

2. Quality Control at the Type Command Level 

Management at the prototype site is concerned with 
operational characteristics. The quality factors associated 
with these characteristics are: 
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- maintainability 

- testability 

- flexibility 

- correctness 

- reliability 

- efficiency 

- integrity 

- usability 

Assurance of maintainability at this level is important 
because of the requirement to be able to correct and upkeep 
the software code. Type Commands do not possess the funds and 
personnel to support a large maintenance effort on THAIS. 
This drives the need to ensure that the maintenance required 
is capable of being completed. 

The reasons for the importance of testability are 
similar to those of maintainability. Type Commands strongly 
desire a proven system, one that has been tested on site. 
Ensuring testability means ensuring that system tests can be 
completed within available Type Command funding limitations 
and assigned personnel. 

As with upper management, the flexibility to change a 
program is a necessary function within THAIS because dynamic 
situations under the cognizance of Type Commands require 
continual adaptation by management. Type Commands are the 
experts on their mission objectives and are the best personnel 
to monitor the correctness of the system. The ability of the 
system to reliably perform for an extended period must also be 
monitored at the Type Command level. Since they will be the 
users and will not want to operate a system which is consis- 
tently inefficient and unreliable. Type Commands serve as the 
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best judges of system efficiency and reliability. Data 
security is another factor which is best monitored at the Type 
Command level since they know the security requirements and 
the consequences of violating those requirements. Finally, 
the usability of the system can only be monitored at this 
level because the system is used at this level. Outside 
software developers do not sufficiently anticipate the ability 
of personnel unfamiliar with the system, primarily due to high 
turnover rates, to use and become proficient with the system. 

Quality control is performed at the Type Command level 
by constant interaction between the IE development team and 
the Type Command personnel assigned at the prototype site. 
This team is responsible for ensuring the accuracy of the data 
and its relationships as well as guiding the prototype site 
personnel in the proper direction for modeling the organiza- 
tional data. 

C. THAIS PROJECT DEVELOPMENT QUALITY CONTROL 

The assurance of quality control within the physical 
development of the system is accomplished by the design 
software itself, lESC' s USER: Expert Systems. Improper 
entity, attribute and association relationships are automati- 
cally detected and provided to the user in report format upon 
request using the USER: Project module. The errors are then 
manually corrected, ensuring an accurate database. [Ref. 23] 
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The user only becomes aware of errors if he specifically 
recjuests a report. This is inadequate since much design work 
may be completed based on faulty data relationships. The work 
would have to be completed again with the correct information 
thereby delaying the design process. One feature of the 
software which exposes errors is the data mapping module, 
USER: Plotmaster . This module will not map incorrect data 
relationships. Unfortunately, this is the only module which 
does not tolerate errors. [Ref. 23] 

D. SUMMARY 

Ensuring a high quality product is a constant process of 
monitoring the activities of the project management and the 
project development teams. Without continual attention, the 
product will be less likely to meet user requirements and 
therefore be unsatisfactory. Although lESC' s software 
requires additional error detection capabilities during the 
actual data entry phase, the IE process is well suited for 
conducting quality control. The typical problems associated 
with management information system design and implementation 
are listed below. The close interaction between management 
and development teams which the IE methodology espouses can 
overcome these problems . 

The quality factors described earlier can be sufficiently 
provided for within the framework of IE. This methodology is 
centered on an organization's data and involves the user and 
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management to a high degree in the design process. With these 
characteristics, all eleven quality factors can be accomodated 
during the IE process thereby ensuring high customer satisfac- 
tion. Also, effective use of CASE tools speeds system 
development, thereby enhancing quality in that the developer 
is able to commit more time to requirements analysis and 
system design. The following taible represents the projected 
savings resulting from the use of CASE tools [Ref. 24 :p. 150] . 



THE ADVANTAGES OF 
AUTOMATION 


Program 

size 




Projected savings with CASE* 
compared with current methods 

Cost Time Staffing 


SMALL 




95% 


97% 


0% 


MEDIUM 




94 


92 


50 


LARGE 




92 


83 


88 


VERY LARGE 


87 


80 


37 



Table 1 Advantages of CASE Technology 

’Computer-Aided Software Engineering 



The stable information systems architecture produced from 
IE is, in itself, a form of quality control. It ensures that 
an organization, such as a Type Command which has several 
dispersed and specialized functional areas, is able to sharply 
focus on its organizational goals. Unfortunately, there are 
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factors which detract from the quality control benefits of IE 
and which render IE an insufficient methodology as practiced 
on the THAIS modernization project. The benefits and problems 
associated with IE on the THAIS project are discussed in the 
following chapter. 
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V. RESULTS of CNSP IE EFFORTS 



The THAIS system represents a very good example of the need 
for IE during system design and implementation. Type Commands 
work with large volumes of data from many different functional 
areas, with much of the data redundant or irrevelent . They 
also use several management information systems which ideally 
should be integrated into a single, relational database 
management system. IE is a methodology which was designed to 
rectify this situation and was utilized on the THAIS redesign 
for this reason. 

The utilization of IE during the redesign project had 
several benefits. IE allowed an organization such as CNSP to 
develop a stable information systems architecture. This 
stable foundation will enable the organization to change its 
policies and objectives without attention to redesigning its 
information system. Involvement with data modeling at the 
strategic and tactical levels was very helpful in determining 
the basis for a useful database design. Essential, relatively 
constant data, independent of processes that may change, were 
captured for use in the database design. Also, intensive 
management and user involvement ensured that the data was 
complete and accurate . This involvement provided a better 
understanding of the organization and its purpose throughout 
CNSP's distinct functional areas. However, there were several 
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difficulties experienced with IE during the THAIS moderniza- 
tion project. 

A. REASONS for DISSATISFACTION with lESC's IE 

There are several corporations which specialize in IE with 
only minor variations in their interpretations of the method- 
ology. lESC was chosen as the contractor for the THAIS 
modernization therefore their methodology and their CASE tool, 
USER: Expert Systems, was utilized. 

lESC was contracted to design a database using IE to 
identify CNSP's strategic objectives and operational require- 
ments during a nine month time- frame from January to September 
1990. lESC assigned two full-time representatives or consul- 
tants to the THAIS project. These men worked with CNSP staff 
and NCTS San Diego personnel to map CNSP's information 
requirements through strategic, tactical, operational and 
process modeling. Prior to each modeling stage, a one week 
workshop was held to introduce and familiarize the participat- 
ing personnel with the goals and details of each modeling 
stage. The workshops included personnel from other Type 
Commands, specifically from COMSUBPAC, Pearl Harbor and CNSL, 
Norfolk. Other Type Commands were expected but unable to 
attend. Representation from several Type Commands was desired 
in order to facilitate designing a system which would satisfy 
the requirements of all Type Commands and not be unique to an 
individual Type Command. For clarification, a Type Command is 
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an organization which controls a specific group of assets 
which are surface forces, air forces, and submarine forces. 
Each Type Command has equivalent or similar functional areas 
and information requirements. Input from each Type Command is 
necessary to more accurately map information requirements and 
design a more useful system. 

Strategic, Tactical and Operational modeling proceeded 
smoothly but at an unexpectedly slow pace [Ref 16: p. 1]. The 




slow pace can be attributed to several factors. First, data 
modeling was not treated as a full-time effort [Ref. 16:p. 1]. 
Personnel from CNSP staff, the primary project 'experts' on 
the organizational data and data relationships, were committed 
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to their primary duties and often unavailable to provide 
critical input. Also, the recjuirement for and procedures of 
many data and information flows had to be verified in CNSP and 
higher chain of command documents during the modeling process 
which led to significant time delays. In most situations the 
procedures and data recjuirements were nearly identical across 
Type Commands but a few situations existed where there were 
variations. These situations dictated the need to standardize 
the dissimilar procedures which incurred unexpected delays. 
Finally, data modeling proved to be a difficult and tedious 
process, especially the identification of entities and their 
associated normalization. 

According to Clive Finkelstein, the founder of lESC, an IE 
project should have between 10-20 entities per tactical model 
with approximately 20 tactical models per strategic model and 
an entity/attribute ratio of 1:5 at the tactical level. The 
strategic model should have 250-750 entities [Ref 2:p. 246]. 
The Readiness Reporting Module, the second of seven tactical 
areas to be modeled in the THAIS project, contained 299 
entities and 478 attributes for an entity/attribute ratio of 
3:5 [Ref. 25:pp. 41,77]. These figures are significantly 
higher than the expected number for a typical IE project for 
two reasons. First, the project was not typical in that the 
scope of the project was much larger than expected by lESC. 
Second, the data was normalized to an unmanageable level which 
created an excessive number of entities and attributes. 
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According to the James Martin Associates Corporation, a very 
respected IE firm, "...a project with that many entities in 
one tactical area is a recipe for failure." [Ref. 26] 

The difficulty with such a large number of entities and 
attributes begins with the normalization. Theoretically, N*"** 
normal form is the ultimate in normalized data. Generally, 
higher normalized forms of data dictate more storage space and 
increased access time, two undesiraible traits, but incur more 
flexibility within a relational structure. [Ref. 20 :p. 1] 

As the same atomic data is represented by more rela- 
tions, additional keyed fields are required within each 
relation to perform the joins necessary for data access. 
This has the effect of greatly increasing the data storage 
requirements and therefore the data transfer times. 

As additional relations are created, each relation 
requires at least one more disk access to retrieve data 
along with a keyed search to determine the data location 
(which itself may be much greater than one access) . 

[ Re f . 2 0 : p . 2 ] 

lESC's approach in the THAIS project was to normalize the 
data to fifth normal form (5NF) . This form is significantly 
higher than the typical third normal form (3NF) used on many 
projects. Although 5NF provides a major increase in the 

9 

flexibility of a system and is capable of being done, it is 
not practical. An example of this added flexibility within 
THAIS is illustrated with the following comparison. The 
entity 'CASREP' has four attributes: CASREP Age; CASREP 

Number; CASREP Total Requisitions; and Job Sequence Number. 
The entity 'CASREP Message' has only one attribute, CASREP 
Message Serial Number. Access to the former entity requires 
retrieval of all four attributes but access to the second 
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entity requires retrieval of only one attribute. The one-to- 
one entity/attribute characteristic of ' CASREP Message' allows 
a greater degree of flexibility within the relational struc- 
ture. However, the effort required to get to the 5NF of 
' CAS REP Message' and the added storage, time and money 
requirements do not justify the additional flexibility over 
3NF . In addition, all of the data modeled during the IE 
sessions and normalized to 5NF was subsequently reverted to 
approximately 3NF when the software developers at NCTS San 
Diego and Idaho National Engineering Laboratories (INEL) were 
unable to sufficiently generate code for a relational database 
in 5NF [Ref. 16;p. 3]. 

Another problem associated with the IE effort was in the 
team size assigned to the project. Two full-time consultants 
and five full-time users comprised the team [Ref. 27]. 
Although this team size falls within the guidelines set forth 
by Clive Finkelstein of no more than six users or managers per 
project team, the team did not consistently operate together 
[Ref. 2:p. 263]. The two consultants often split their time 
with the group and the users often entered and departed the 
modeling sessions irregularly as their additional duties 
required. 

Process modeling proved to be a major problem with the IE 
portion of the THAIS project. This phase requires the 
completion of the following tasks: 

- Determine the business processes associated with the 
stable Operations Data Model. 
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- Design screen forms and reports based on the stable 
Operations Data Model. 

- Document the procedures necessary to accomplish business 
procedures . 

- Produce design documentation for implementation in a 
variety of languages and DBMS products. [Ref. 28 :p. vi] 

These tasks were not completed for several reasons. The 
project up to the process modeling stage went smoothly, but 
this stage of the project became burdensome causing the 
project to fall behind schedule. According to one team 
member, this phase "...has proven to be the most confusing, 
labor intensive, and difficult phase." [Ref. 16:p. 1] The 

reasons for falling behind schedule and the difficulty 
experienced by the team members can be attributed to the 
following factors as delineated by the CNSP Special Project 
Officer, Capt. Shillingsburg: 

- Failure by the contractor to communicate the difficulty of 
this phase. Many of the 'users' were led to believe the 
modeling would be completed in three weeks. 

- Failure of the contractor to provide experienced facilita- 
tors during process modeling resulted in confusing and 
poor guidance on how to proceed and what was required. 

- A software problem in the lESC tool resulted in the 
'users' working several weeks with out-of-date reports and 
also reduced lESC support to the 'users' as the contractor 
devoted considerable time trying to resolve the software 
problem . 

- Process modeling is complicated and a skill that cannot be 
learned in one week. 

- The CASE tool used by lESC supports the Strategic, 
Tactical, and Operational modeling phases but does not 
support the Process modeling phase. [Ref. 16:p. 2] 
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Process modeling was considered a failure after approxi- 
mately six weeks of effort. A great deal of the difficulty 
resulted from a lack of organization and a lack of knowledge 
on the lESC consultants' part [Ref. 29:p. 1] . As acknowledged 
by an lESC representative, lESC has not had great success with 
process modeling on other projects and the large size of the 
THAIS project made process modeling especially difficult 
[Ref. 29 :p. 1] . 

As a result of the problems identified above, CNSP became 
dissatisfied with IE. The inability of the software develop- 
ers to utilize the data modeled through IE was itself enough 
evidence against IE and lESC to not renew lESC' s contract for 
additional THAIS modules and to continue the project under the 
direction of the software developer, INEL. 

B. INTRODUCTION OF INEL' s SAGE METHODOLOGY 

As a THAIS modernization milestone approached, the delivery 
of the first module within the Readiness Reporting functional 
area, the CASREP module, in September 1990, the project was 
behind schedule [Ref. 16 :p. 2] . The software developers were 
supposed to receive the final database design from lESC in the 
June/ July timeframe. However, the design was not delivered 
until early August. INEL, which was tasked by NCTC with using 
ADA to develop the software, reviewed the design and found it 
unsatisfactory and incompatible with their SAGE development 
methodology . 
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The primary issue was the normalization of the data to 5NF. 
INEL discovered that the 5NF was too detailed for use with 
their ADASAGE software package which created several problems 
during implementation. The problems discussed earlier with 
5NF and the additional problem of the inability of DOS to 
handle large access times required the database to be rede- 
signed in 3NF. [Ref. 30] 

INEL found the documentation of the delivered database 
design to be inadequate. Therefore, several functional 
experts from CNSP and NCTS San Diego were required to work 
with INEL during the early stages of software development to 
provide explanations of the data elements [Ref. 30] . Although 
INEL faced several problems with the IE designed database, it 
was quite pleased with the completeness of the data elements. 
This enabled the software development to proceed rapidly, 
approximately six weeks from start to completion of the first 
prototype [Ref. 30] . 

One final problem which INEL had to solve during software 
development was the lack of hardware consideration during the 
database design. Although hardware is not considered an 
important aspect during the IE process, in fact it is deliber- 
ately disregarded, the SAGE software development methodology 
requires its consideration. Therefore, INEL had to analyze 
the hardware requirements and alter the database design to fit 
those requirements. This alteration was primarily the 
denormalization of the data to 3NF in order to solve the 
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access time limitations within DOS since DOS was the operating 
system of choice on the THAIS PC platforms. [Ref. 30] 



C. BENEFITS OF INEL'^ S SAGE METHODOLOGY 

INEL' s SAGE software development methodology was introduced 
in Chapter II. This methodology provides a rapid prototyping 
approach which allows the completion of an initial prototype 
in a few weeks . After review and additional inputs from 
users, subsequent iterations take from a few days to a few 
weeks to produce depending on the complexity of the additional 
enhancements [Ref. 31]. 

The initial THAIS prototype was demonstrated on 30 Septem- 
ber 1990. Several iterations have since been produced and the 
users are still recommending changes to the software. 
However, the continual user involvement and subsequent fine- 
tuning of the prototype is a significant problem. Many times 
the prototype: 

- might not include all aspects of the intended system. 

- might have been implemented using resources that will not 
be available in the actual operating environment. 

- might not be able to handle the full workload of the 
intended system. [Ref. 32 :p. 13] 

Fortunately, the THAIS prototype has been revised to ensure 
compliance with user and hardware requirements. User refine- 
ments could continue indefinately but a deadline of 31 March 
1991 has been set for all further refinements. This will be 
the baseline model for the CASREP module. [Ref. 31] 
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INEL is working with NARDAC Norfolk and NCTS San Diego on 
two additional functional areas. Both organizations are 
learning to use the ADASAGE library and to utilize the SAGE 
methodology. INEL is providing personnel in training and 
expert support roles to work with NARDAC Norfolk in developing 
the Aviation Maintenance area and with NCTS San Diego in 
developing the Readiness Reporting area. The goal is to be 
independent from INEL at the end of fiscal year 91 in order to 
develop future modules totally in-house and to allow the Naval 
Air Forces Atlantic and Pacific and the Naval Surface Forces 
Atlantic and Pacific to become independent of the Honeywell 
DPS-6 minicomputers by September 91. [Ref. 31] 

INEL' s methodology has proven to be very effective in the 
development of the THAIS module. CNSP's satisfaction with the 
methodology and INEL's development efforts have given support 
to SAGE. The success of the prototype was not totally 
dependent on SAGE/ the IE effort in modeling the data was 
essential as well . 

There are several advantages of IE v , ch were discussed in 
Chapter II. The advantages of the SAGE methodology were 
discussed in Chapter II also. Although both efforts were 
independent, they required some interdependence. The output 
of IE, the database design, was the input to the software 
development. CNSP's stated lessons learned from the involve- 
ment of both techniques are: 

- A small experienced professional team of ADA programmers 
with good tools can turn out applications in 60-90 days. 
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- Rapid prototyping should start much earlier in the 
Information Engineering (IE) cycle essentially replacing 
the operational and processing phases. 

- Active, articulate functional user involvement is essen- 
tial to success. 

- Rapid prototyping dramatically increases user ability to 
articulate needs which can be translated to software. 
[Ref. 33:pp. 3-4] 

These lessons learned are valid and useful in the evaluation 
of the project but they pertain to rapid prototyping almost 
exclusively. However, the justification for using IE must be 
emphasized. 

Although CNSP's dissatisfaction with IE is stated explicit- 
ly in Reference 16, IE is a methodology which can be very 
useful to future DON projects. Its ability to effectively map 
organizational data and to establish a stable architecture 
which supports user requirements is exceptional. If used in 
conjunction with a Rapid Prototyping software development 
methodology such as SAGE, user satisfaction with the software 
and project management s satisfaction with overall project 
completion should improve dramatically over conventional 
database design and software development techniques. 
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VI. CONCLUSION and RECOMMENDATIONS 



The IE effort on the THAIS modernization project has had a 
significant impact on the development of database systems for 
the U.S. Navy. The effort has given upper level management a 
strategic information systems planning methodology which is 
more appropriate to the development of a staible information 
systems architecture than more traditional approaches. Type 
Commands such as CNSP have been overwhelmed by information 
requirements of upper management and inundated with data from 
several distinct functional areas under their control. CNSP's 
effort in utilizing IE to identify these typical Type Command 
requirements and to define essential data has resulted in a 
successful information systems architecture. This architec- 
ture should remain stable for many years and provide the basis 
from which the organization can adapt to changing require- 
ments . 

Although problems with the IE contractor tainted the 
outlook for IE utilization on THAIS modules yet to be rede- 
signed, the benefits from using IE are substantial. The 
specific benefits are: 

- Comprehensive involvement at the upper, middle and lower 
organization levels ensures complete and accurate data. 

- User involvement throughout the design process instills a 
sense of ownership which favors delivery of a system that 
will not go unused do to lack of user friendliness or lack 
of understanding of the system's capabilities. 
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- strategic focus on policies and objectives which enables 
the design of a system more responsive to a changing 
environment . 

- Concentration is on capturing organizational data and 
establishing a stable information systems architecture 
instead of designing a system to fit specific hardware. 

- Utilization of CASE tools automates the design process and 
allows project personnel to concentrate their efforts on 
req[uirements analysis and data refinement which speeds the 
design process and increases the quality of the end 
product . 

Although CNSP's efforts resulted in establishing IE as a 
viable planning and design methodology for use on other DON 
projects, the effort was not without its pitfalls. Several 
problems existed in the actual IE process which delayed the 
delivery of the database design to the software developer. 
The contractor, lESC, was behind schedule for a large portion 
of the project due to difficulties with process modeling. 
This stage proved to be the most difficult and time-consuming 
portion of the whole project. Inadequate preparation of 
lESC' s consultants during this stage and the inherent diffi- 
culty of conducting process modeling caused the project to 
fall behind schedule. Also, the CASE tool used, lESC's USER: 
Expert Systems , did not support process modeling. The 
delivery of the database design to the software developer 
entailed problems as well. The software developer, tasked 
with delivering a usable system coded in ADA, could not 
utilize the database design in the form which lESC delivered 
it. INEL determined the design to be too detailed for its 
software package, ADASAGE, and consequently had to denormalize 
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the data to approximately 3NF in order to properly implement 
the design. INEL used its SAGE software development methodol- 
ogy^ which incorporates Rapid Prototyping^ to deliver a usable 
prototype in just six weeks. 

The problems associated with IE resulted in CNSP's dissat- 
isfaction with the methodology. Unfortunately, IE's benefits 
seem to have been overshadowed. IE, as demonstrated by the 
THAIS modernization, is a valuable tool for planning and 
designing a large database system which will remain stable for 
many years. INEL' s delivery of the software prototype in just 
six weeks while utilizing ADA and Rapid Prototyping also 
demonstrates a useful development process. A technique which 
would benefit DON the most in future design efforts similar to 
THAIS would be to utilize IE and SAGE in conjunction with each 
other . Specifically : 

- The IE portion should utilize strategic and tactical data 
modeling to develop the database design. 

- The IE methodology utilized should have a fully capable 
CASE tool to complete the ’’front end” effort. lESC' s US- 
ER : Expert Systems does provide this support but it fails 
to provide adequate code generation or ’’back end” support. 

- The software development portion should utilize a Rapid 
Prototyping technique to improve the product delivery time 
and to involve the user continually in order to instill a 
sense of ownership and create a very usable system. 

- The contractors involved in future projects should possess 
the proper CASE tools and provide adecjuate support and 
training to the DON users involved in the design process 
in order to eliminate the problems encountered by CNSP 
during process modeling. 

This paper has presented an evaluation of CNSP's efforts in 
the redesign of THAIS. The history and background of both 
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THAIS and IE were discussed. Problems encountered during the 
project were exposed and remedies suggested. The THAIS 
redesign project was successful in that a methodology, IE, 
which seeks to establish a stable information systems archi- 
tecture for a dynamic organization such as a Type Command was 
utilized. The need for this stable architecture is essential 
in order to prevent ad hoc responses to long term problems 
which is frequently the situation. 
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